-
Notifications
You must be signed in to change notification settings - Fork 10
Matter Element and MaterialP #79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Update material.md Update material.md Update element-parameters.md Update element-kinds.md
Update aperture.md to use MaterialP Update element-parameters.md Update element-kinds.md
|
There are several issues that are raised here. For one there is the matter of units. Do we want to have a consistent set of units which would make densities kg/m^3? I know this looks kind of ugly but from a practical point of view it will lead to less errors. |
|
Another issue is material naming. For elements and compounds I would use the OpenPMD naming convention #33. And I would get away from the |
|
Another issue is that having a single |
|
Yes. density in kg/m^3 is ugly but reasonable. Do you have a suggestion for the atomic mass? Is there a list of OpenPMD materials? I could not find any reference on that. As someone working on fragment separators, to me everything is just matter with composition and shape. |
Also: Vacuum windows was mentioned. This should definitely be in a category by itself. |
|
There are a few conflicts to be resolved after the latest merge in |
|
Comments from today: define ratios more precise (mass/number of atoms/...) |
Updated VersionMatter ElementMaterials which fully occupy the beamline, like targets, (stripper-)foils, vacuum windows, gas cells or degraders. Element parameter groups associated with this element kind are:
MaterialP: Definition of materialsThe definition of materials is inspired by Geant4's material handling. One can either use the name, which is the symbol of an element ( Alternatively custom elements can be defined by and compounds by
Examples
Liquid deuterium can be defined with the and deuterated polyethylene (C2H4) can be defined based on the previous definition |
| - density: # [kg/m^3] The density of the material | ||
| - Z: # [int] The atomic number | ||
| - A: # [int] The mass number (equals Z+N) | ||
| - N: # [int] The neutron number | ||
| - m: # [u] The atomic mass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not only use the name? Something like #3He is should be sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like using the #... notation where sensible, so we keep that aspect compatible with openPMD species: https://github.com/openPMD/openPMD-standard/blob/upcoming-2.0.0/EXT_SpeciesType.md
(Material here describes more than what I linked)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will there be conflicts with # as begin-comment marker?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. We should be ok if we define it as a quoted string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The non-# version is definitely easier to machine read, just more verbose to human write.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DavidSagan I have a very general question: Is the API which the translator exposes to the interface layer different from what is defined in the PALS standard? Is the PALS standard which we describe here only for the file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First there is the PALS schema which is language agnostic and defines things like parameter names and how to structure the information tree. Then there will be (in development) PALS standards for each language (YAML, etc.) that PALS lattice files can be written in that mirrors the schema. For the translators, what is exposed to the interface layer will be 1) the information in the lattice file and 2) what could be termed "lattice expansion" information which would be things like expression evaluation, floor coordinate evaluation, expanded beam lines, etc.
And yes, what the schema describes is only for the file. The individual translators will document their API. We could talk about trying to have some uniformity between translators but remember the translators will be in different languages so it will not be possible to have a completely uniform API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. It is sensible to try to mirror the PALS schema also in APIs, as much as possible/sensible, e.g., when defining properties/function/class names.
Does not prevent to add on top additional helper functions, e.g., to transform, query, convert values between each other, etc.
| - name: "Deuterium(l)" | ||
| - density: 160 | ||
| - Z: 1 | ||
| - A: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deuterium has A = 2.
| - A: 1 | |
| - A: 2 |
| location: ENTRANCE_END # [enum] Aperture location switch | ||
| vertices: [] # [array] Array of vertex points. See below. | ||
| material: "" # [string] Material of the Aperture | ||
| material: "" # [MaterialP] Material of the Aperture |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it is not a string anymore:
| material: "" # [MaterialP] Material of the Aperture | |
| material: null # [MaterialP] Material of the Aperture |
|
|
||
| ```{code} yaml | ||
| MaterialP: | ||
| - state: # ["solid", "liquid", "gas"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's have all four states of matter for completeness? :)
| - state: # ["solid", "liquid", "gas"] | |
| - state: # ["solid", "liquid", "gas", "plasma"] |
| Liquid deuterium can be defined with the `ElementP` parameters: | ||
| ```{code} yaml | ||
| ElementP: | ||
| - name: "Deuterium(l)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does the (l) suffix stand for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"liquid"
| MatterP: | ||
| - thickness: # [m] Thickness in meter | ||
| - area_density: # [kg/m^2] Density times thickness | ||
| - MaterialP: # [MatterP or name] the material |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Formatting:
| - MaterialP: # [MatterP or name] the material | |
| - MaterialP: # [MatterP or name] the material |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you mean:
| - MaterialP: # [MatterP or name] the material | |
| - material: # [MaterialP] the material |
Note that I also removed or name because we should uniformly allow (or disallow) referencing parameter groups by name (currently, we only do this for element kind). Let's keep it simple for now.
| - [**ApertureP**](#s:aperture.params): Aperture parameters of the outer (blocking) aperture. | ||
| - [**BodyShiftP**](#s:bodyshift.params): Orientation of element with respect to its nominal position. | ||
| - [**FloorP**](#s:floor.params): Floor position and orientation. | ||
| - [**MetaP**](#s:meta.params): Meta parameters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume adding the MatterP paramter group is the whole idea of this element:
| - [**MetaP**](#s:meta.params): Meta parameters. | |
| - [**MatterP**](#s:matter.params): Matter parameters. | |
| - [**MetaP**](#s:meta.params): Meta parameters. |
| - [**ReferenceP**](#s:ref.params): Reference parameters. | ||
| - [**ReferenceChangeP**](#s:refchange.params): Reference energy change and/or reference time correction. | ||
| - [**TrackingP**](#s:tracking.params): Tracking parameters. | ||
| - [**MaterialP**](#s:material.params): Matter parameters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah here it is. Then just alphabetic ordering :)
| - [**MaterialP**](#s:material.params): Matter parameters. |
I think you mean MatterP, not MaterialP.
|
This is great! I think I spot a possibility to simplify this a little by using 2 instead of 3 parameter groups, let's discuss tomorrow :) |
|
My idea was to separate the material properties |
|
Ah, good point. |
|
@danielkallendorf After thinking it over, to answer your question, I would advocate that things like atomic masses can be |
Matter
Provide a proposed name for the lattice element. This can be an abbreviation, and should be at most 1-2 words (e.g., Quadrupole).
Matter Element (replaces foil)
Materials which fully occupy the beamline, like targets, (stripper-)foils, vacuum windows, gas cells or degraders.
This element can cause energy-loss, angualar and energy straggling, as well as change of charge state or particle type.
MaterialP: Definition of materials
The definition of materials is inspired by Geant4's material handling. One can either use the name, which is the symbol of an element (
"G4_Cu","G4_H", ...) or compound ("G4_STAINLESS-STEEL").In the future all elements and materials in the G4 Manual will be supported.
Alternatively custom elements can be defined by
and compound by
Physical model
I assume a material should be described precise enough by state, density, thickness and composition.
Note: Due to the stochastic nature of beam-matter interaction, the Taylor-/transfer-map-formalism can only account for the mean average effect.